<html>
<head>
<title>Workflow components</title>
<link href="book.css" rel="stylesheet" type="text/css"/>
<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
<link rel="home" href="index.html" title="Modeling Workflow Engine Reference"/>
<link rel="up" href="index.html" title="Modeling Workflow Engine Reference"/>
<link rel="prev" href="index.html" title="Modeling Workflow Engine Reference"/>
<link rel="next" href="workflow_reference_included_workflow_components.html" title="Included Workflow Components"/>
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Workflow components</h1>
<div class="section" title="Workflow components">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both">
<a name="workflow_reference_workflow_components"/>Workflow components</h2>
</div>
</div>
</div>
<p>At the heart of the workflow engine lies the
    <code class="classname">WorkflowComponent</code>. A workflow component represents
    a part of a generator process. Such parts are typically model parsers,
    model validators, model transformers and code generators. MWE ships with
    different workflow components which should be used where suitable, but you
    can also implement your own. The only thing you have to do is to implement
    the
    <code class="classname">org.eclipse.emf.mwe.core.WorkflowComponent</code>
    interface:</p>
<pre class="programlisting">public interface WorkflowComponent {

	/**
	 * @param ctx
	 * 		current workflow context
	 * @param monitor
	 * 		implementors should provide some feedback about the progress
	 * 		using this monitor
	 * @param issues
	 */
	public void invoke(WorkflowContext ctx, ProgressMonitor monitor, Issues issues);

	/**
	 * Is called by the container after configuration so the
	 * component can validate the configuration before invocation.
	 *
	 * @param issues -
	 * implementors should report configuration issues to this.
	 */
	 public void checkConfiguration(Issues issues);

}</pre>
<p>The <code class="methodname">invoke()</code> operation performs the actual
    work of the component. <code class="methodname">checkConfiguration</code> is used
    to check whether the component is configured correctly before the workflow
    starts. More on these two operations later.</p>
<p>A workflow description consists of a list of configured
    WorkflowComponents. Here is an example:</p>
<pre class="programlisting">&lt;workflow&gt;
	 &lt;component class="my.first.WorkflowComponent"&gt;
			&lt;aProp value="test"/&gt;
	 &lt;/component&gt;
	 &lt;component class="my.second.WorkflowComponent"&gt;
			&lt;anotherProp value="test2"/&gt;
	 &lt;/component&gt;
	 &lt;component class="my.third.WorkflowComponent"&gt;
			&lt;prop value="test"/&gt;
	 &lt;/component&gt;
&lt;/workflow&gt;</pre>
<p>The workflow shown above consists of three different workflow
    components. The order of the declaration is important! The workflow engine
    will execute the components in the specified order. To allow the workflow
    engine to instantiate the workflow component classes, WorkflowComponent
    implementations must have a default constructor.</p>
<div class="section" title="Workflow">
<div class="titlepage">
<div>
<div>
<h3 class="title">
<a name="workflow_reference_workflow"/>Workflow</h3>
</div>
</div>
</div>
<p>A workflow is just a composite implementation of the
      <code class="classname">WorkflowComponent</code> interface. The
      <code class="methodname">invoke</code> and
      <code class="methodname">checkConfiguration</code> methods delegate to the
      contained workflow components.</p>
<p>The Workflow class declares an
      <code class="methodname">addComponent()</code> method:</p>
<pre class="programlisting">public void addComponent(WorkflowComponent comp)&lt;/para&gt;</pre>
<p>which is used by the workflow factory in order to wire up a
      workflow (see next section <span class="emphasis">
<em>Workflow
      Configuration</em>
</span>).</p>
</div>
<div class="section" title="Workflow Components with IDs">
<div class="titlepage">
<div>
<div>
<h3 class="title">
<a name="workflow_reference_components_with_IDs"/>Workflow Components with IDs</h3>
</div>
</div>
</div>
<p>If you want your workflow components to have an ID (so that you
      can recognize its output in the log) you have to implement the interface
      <code class="classname">WorkflowComponentWithID</code> and the
      <code class="methodname">setID()</code> and <code class="methodname">getID()</code>
      operations. Alternatively, you can also extend the base class
      <code class="classname">AbstractWorkflowComponent</code>, which handles the ID
      setter/getter for you.</p>
</div>
<div class="section" title="More convenience">
<div class="titlepage">
<div>
<div>
<h3 class="title">
<a name="workflow_reference_convenience"/>More convenience</h3>
</div>
</div>
</div>
<p>There is another base class for workflow components called
      <code class="classname">AbstractWorkflowComponent2</code>. Its main feature is,
      that it has a property called <span class="property">skipOnErrors</span>. If set
      to <code class="literal">true</code>, it will not execute if the workflow issues
      collection contains errors. This is convenient, if you want to be able
      to skip code generation when the preceding model verification finds
      errors. Note that instead of implementing
      <code class="methodname">invoke(...)</code> and
      <code class="methodname">checkConfiguration(...)</code>, subclasses of
      <code class="classname">AbstractWorkflowComponent2</code> have to implement
      <code class="methodname">invokeInternal(...)</code> and
      <code class="methodname">checkConfigurationInternal(...)</code>. This is
      necessary to allow the framework to intercept the invocation and stop it
      when there are errors in the workflow.</p>
</div>
</div>
</body>
</html>
